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ABSTRACT 


A meta-level facility for control in a logic program- 
ming shell is implemented. The control information in the 
form of meta -knowledge essentially specifys how to use the 
object-level knowledge. With the help of this facility a 
user can define his strategies and heuristics separately 
from the program and achieve better performance of execu- 
tion. 

We have also looked at the problem of specifying func- 
tional relation information in logic programming. The notion 
of functionality is declarative and independent of any 
search-strategy used in the inference. We have developed an 
algorithm for the interpreter which makes use of functional 
information and eliminate unnecessary recomputations in the 
inference of a goal. 



CONTINTS 


Chapter Page 

1 INTKODDCTION 1 

1 . 1 Logic Programming 1 

1.2 Language For Logic Programming 2 

1.2.1 Prolog 2 

1.2.2 Prolog Interpreter 2 

1.3 Problem Definition 5 

1.3.1 Problem Of Control 5 

1.3.2 Functional Relations In 8 

Logic Programming 

1.4 Aim Of This Work 8 

1.4.1 Meta-Control In 8 

Logic Frogranning 

1.4.2 Functional Relations In 10 

Logic Programaaixkg 

2 META-CONTROL IN LOGIC PROGRAlfflllNG 11 

2.1 Introduction 11 

2.2 External Control Combined With Program 11 

2.3 External Control Separated Frc» Program 12 

2.4 Organisation Of Meta-Level Control 13 

2.5 Operation Of Interpreter With Meta-Control 14 

2.5.1 In Absence Of Meta-Clauses 14 

2.5.2 In Presence Of Meta-Clauses 14 

2.5.3 Analysis Of Meta-Clauses 15 

2.5.4 Semantics Of Iteta-Predicate 16 

2.6 Case Studies 18 

2 . 7 Impl^nentation 25 

2.7.1 Representation Of Database 25 

2.7.2 Representation Of Environment 25 

2.7.3 Inference 26 

2.7. 3.1 Data Structure 26 

2 . 7. 3 . 2 Data Structure Definition 27 

2 . 7 . 3 . 3 Algorithm For Meta-Control 28 

2 . 8 Conclusion 30 



3 


FUNCTIONAL RELATIONS IN LOGIC PROGRAMMING 31 

3.1 Functional Relation In 31 

Loslc Program 

3.2 Functional Computations In 32 

Logic Program 

3.2.1 Functionality vs Detezminacy 32 

3.2.2 Deterministic Computations In 33 

Logic Program 

3.2.3 Cut and Functional Computations 33 

3.3 Interpreter With Fd- Information 35 

3.3.1 Terminology 35 

3.3.2 Algorithm For Interpreter 39 

3 . 4 Implementation 50 

3.4.1 Representation Of Database 50 

3.4.2 Representation Of Environment 50 

3.4.3 Representation Of Fd- Information 51 

3.4.4 Compilation Of Fd-Information 52 

3.4.5 Inference 54 

3 . 5 Conclusion 58 

REFERENCES 59 

APPENDIX 1 61 

APPENDIX 2 63 



l.INTRODOCTION 


1 . 1 Logic Frogranoning 

Logic programming began in early seventies when Kowal- 
ski CK74] gave the idea of using logic as a language for 
programming. It has an abstract underlying model viz. logic 
which provides a precise language for ones goal, knowledge, 
and assumptions. Ideally, logic programming only requires 
that knowledge about the problem and the assumptions which 
are sufficient to solve the problem be stated explictly as 
logical axioms. The logic program then can be executed by 
providing it with a problem i.e. a goal statement that is to 
be inferred. The execution of the program is an attempt to 
infer the goal statement given the assumptions in the logic 
program. This makes the logic program simple and declara- 
tive. 


As pointed out by Kowalski, logic programs besides 
being declarative in nature have a procedural interpreta- 
tion too. A program clause i.e. 

A <- Bl, B2, ... ,Bk. 

can be regarded as a definition of procedure A. Further if 

< - 61 , G2 , ... , Gn 

is a given goal clause then each of 6j is regarded as a pro- 
cedure call . Procedural reading of the program clause will 
look like '* goal A is true if goal G1 and goal G2 and 
.... and goal Gn are true . ’’ Thus procedural interpretation 
of logic together witk its declarative nature makes it a 



very powerful language. 

1.2 Language For Logic Programming 
1.2.1 Prolog 

The idea of using first order logic or at least a sub- 
stantial subset of it as a programming language was quite 
promising which resulted in the design of the language Pro- 
log [CM84] [SS86] . It is based on the Horn Clause subset of 
the logic. Every program clause whether it is representing 
knowledge for solving the problem or goal, has to be a Horn 
Clause. In a program clause i.e. 

A <- Bl, B2 Bn. 

A is called as head or consequent of the clause and 
Bl,...,Bn is called body or antecedent of the clause. If the 
body of the clause is absent then its a fact which is always 
true and if the head is absent then its a goal clause. When 
both head and body are present then its a anile. 

1.2.2 Prolog Interpreter 

The Prolog program, which is a set of Horn Clauses, is 

i 

executed by specifying a goal 

<- G1 , . . . , Gn . 

The interpreter starts execution by repeatedly executing 
inference cycles till the empty goal is reached. Each infer-' 
ence cycle takes a current goal to prove say 

<- Cl Ck. 

It chooses the leftmost literal in the goal i.e. Cl and 
searches the database of program clauses to choose t-he firsh 
clause say 



A <- Bl, ... , Bn. 


such ■bha't the head of the clause i.e. A unifies with the 
chosen literal with the substitution s. The body of the 

clause Bl,...,Bn is substituted in place of the chosen 

literal Cl and the substitution s is applied which results 

in the new goal 

(Bl, ... ,Bn,C2, . . . Ck) s 

to be solved. The following example illustrates this 

behaviour 

Example 1_1 : Let us consider an example of family data- 
base with predicates defining parent, male, female and 

mother relations. 

parent (a, e). maleCb) . 

parent(b,f). male(c). 

parent(a,c). femaie(d). 

parent(b,c). female(h). 

parent(c, d) . 

mother (X,Y) <- parent (X, Y) ,female(X) . 

Let the goal specified be mother (M,c), to know who is 

the mother of c. The goal has only one literal so its 

chosen. The literal chosen matches with the head of the rule 

defining mother relation. All the variables in the rule 

chosen are renamed so that they are different from all the 

variables appearing in the goal. The literal chosen unifies 

with the head of the rule and gives the substitution s 

{M/X,c/Y} which results in 

parent(M, c) ,female(M) . 

the new goal to be solved. The complete trace of the proof 
can b^ seen in tefms of the proof tree. 



mother (M, c) . 



Each node in the proof -tree represents the goal or 
resolvent that is to be proved and each branch shows the 
cla.use used for proving the chosen literal. If a node is 
empty it shows success. Whenever a failure node is encoun- 
tered the interpreter moves to the immediate ancestor of the 
failure node and takes the next branch. When the inference 
is proceeding successfully, it is moving down the proof- 
tree, then it is said to be moving in the forward direction. 
Whereas if failure is encountered at any node, it moves up 
the proof -tree and tries the next branch of the proof -tree, 
then it is said to be backtracking. 

The inference-strategy embeded in the interpreter can 
be seen in terms of three decisions which the inteirpreter 
makes in proving the given goal. 

(1) At any node in the proof -tree a literal is to be 
chosen for resolution. In Prolog the interpreter 
chooses the leftmost literal. 

(2) At a node in the proof -tree, after the choice of 
literal is made,, the interpreter has to choose a branch 



for going to next node in the tree. This choice 
correspond to the choice of clause whose head is to be 
unified with the literal. The interpreter takes the 
first branch which correspond to the first clause in 
the order in which they are defined in the program. 

(3) In case of failure at a node, it has to try alter- 
nate branches of the proof -tree. The interpreter goes 
back to the immediate ancestor and takes next branch in 
order until all possibilities for a literal are ulti- 
mately exhausted, then it fails. 

Thd inference-strategy described performs the search 
for a solution of the goal in the search-space in a depth- 
first manner. Unification of a literal with the head of a 
clause performs basic data manipulation operations of vari- 
able assignment, parameter passing, data selection and data 
construction, 

1,3 Problem Definition 

In this thesis we have attempted two problems. One is 
the problem of control in logic programming and the other is 
the problem of specifying functional relation information in 
logic programming. 

1,3,1 Problem Of Control 

The problem of control can be seen in terms of direct- 
ing the search for a solution in the search-space and avoid- 
ing searching useless paths. The problem of controlling' the 
search essentially means determining which part of the 



search-tree is useful to explore and in which order to 
expand the search-tree. This aspect of control concerns the 
search for a solution when inference is moving down the 
proof -tree i.e. in forward direction and is decided by. the 
choice of literal in the resolvent at a node and the choice 
of the clause to be used in resolving the literal. 

Ideally speaking an efficient forward control in terms 
of judicious choice of literal and clause may render back- 
tracking unnecessary. This can be seen in the interpreter 
based on look-ahead of the literals [KM873, The other aspect 
of control becomes important when failure is met at a node 
in the proof -tree. Inference moves up the proof -tree undo- 
ing the branches it has taken and tries the remaining 
branches systematically without taking into account the 
cause of failure. An efficient backtracking control may sug- 
gest which branch to undo. The need of an efficient control 
can be seen by the following example 

Example 1_2 : In the example of the family database (Exam- 
ple 1_1) now we add one more rule for grand-parent relation 
as shown 

grand-parent (X,Y) <- parent (X, Z) ,parent{Z,Y) . 

For finding out the grand-parent of d we execute the goal 
grand-parent(G, d) . The trace of the proof is shown in the 
proof -tree ■ > 




Now instead if we define the rule for grand-father with dif- 
ferent order of literals in the antecedent as 

grand-parent(X, Y) <- parent(Z, Y) ,parent(X, Z) . 
then the inference for the given goal will be faster as 
shown in the proof -tree 

grand-parent ( G , d ) . 

parent(Z,dl,parent(G,Z) . 

I 

parent(G, c) . 

^3 success. 

But with the latter definition of the grand -parent rule the 
same inefficiency will recur if we try to execute the goal 
for finding grand son of a i. e. grand-parent ( a, S). 


One of the main ideas of logic prograimaing, due to 
Kowalski CK793, is that algorithm consists of two distinct 
components : the logic component and the control component. 
The logic component specifies the knowledge to be used in 
solving the problem, while how to use this knowledge consti- 
tutes the control component. The efficiency of an algorithm 
can usually be improved by improving the control component 
withcut changing the logic component. The logic / control 


duality is similar to knowledge/meta-knowledge duality in 



problem-solving as suggested by Davis CD803 . The main Idea 
underlying this distinction is to separate information which 
expresses knowledge from the information which expresses how 
to use that knowledge. Therefore it would be very useful to 
device some way in which user can specify the control- 
information, in the form of meta-knowledge, separately from 
the program. 

1.3.2 Functional Relation In Logic Programming 

The second problem is the problem of specifying func- 
tional relations in logic programming. In general, predi- 
cates in the logic program define relations eunong its argu- 
ments. It is found that very often these relations are func- 
tional in nature. For example the predicate mother (X,y) says 
that X is the mother of Y. There is a unique value of X for 
a given value of Y. There is no way of specifying such 
information describing functionality among the arguments of 
the predicate. Further, the logic programming interpreter, 
although very powerful due to its ability to simulate non- 
determinism, does not make use of such functional informa- 
tion while inferring the goal and ends up doing a lot of 
unnecessary recomputation. This is illustrated by the fol- 
lowing example: 

Example 1_3 : Let there be a goal <- g(X, Y) , t(Y) .The 
predicate g is such that there exists a relation between the 
argument X and Y which is functional in nature i.e. X 
uniquely determines Y. Let the goal be invoked with some 



value of X. Further let the literal g(X,Y) succeed, getting: 
some value for Y and literal t(Y) fail. Now the inter- 
preter, which is unable to make use of the functional infor- 
mation, makes an unnecessary attempt to resatisfy the 
literal g(X,Y) for an alternate value of Y. If the inter- 
preter is made such that it makes use of the functional 
information then such unnecessary recomputation can be 
avoided. 

1.4 Aim Of This Work 

In this thesis we have attempted solutions to both the 
problems described above'. Our implementation would allow 
the user to improve the efficiency of his logic program 
written in VIDHI [586], (a logic programming shell akin to 
Prolog developed at IITK) by providing the control informa- 
tion pertinent to his program separately. Also, we have 
developed an Interpreter which makes use of functional 
information provided by the user. 

1.4.1 Meta-Control In Logic Programming 

A meta-level control facility is proposed by Bincbas 
and Lepape in Metalog. We have developed a meta interpreter 
and implemented the core meta-level facilities proposed in 
Metalog. These facilities enable the user to describe forward 
control as well as control of backtracking in the inference. 
Moreover they also help the user to specify local control 
(specific to a particular literal, clause or resolvent) or 
global control (applicable to whole search-space) of his 
problem. With the help of these facilities, user can 



specify control information pertinent to his program, 
separately, using the same syntactic formalism. 

1.4.2 Functional Relation In Logic Programming 

We have implemented a scheme for specifying functional 
information in a logic program. Further we have developed an 
algorithm for interpreter which makes use of the functional 
information and eliminates unnecessary recomputation. We 
have also shown the correctness of the algorithm. 



2. META-CONTROL IN LOGIC PROGRAMMING 
2.1 In-troduction 

The major reason for inefficiency of a Prolog like 
proof-system is its pre-def ined strategy which makes the 
proof-system highly inflexible and leaves the user with lim- 
ited control over the search-space. To achieve efficiency 
the user should be allowed to control the order of trying 
out program- clauses and the order in which literals in the 
body of a clause can be chosen. This has to be included in 
the definition of the problem which makes it difficult to 
develop, understand and modify the program. Besides, the 
user has no control over backtracking as it is implicitly 
included in the interpreter. Thus due to pre-def ined stra- 
tegy, the user does not have any facility for expressing 
strategies, heuristics and control information specific to 
the program. To do this it is necessary to keep control out- 
side the interpreter and give the user a facility to specify 
the control information externally. 

2.2 External Control Combined With Program 

It is possible to add some control primitives to a 

logic program, in the same syntactic framework, for achieve- 

/ 

ing control over some aspect of the inference process like 
selecting a literal, clause or backtracking point. Also 
these primitives make the logic program more detemlnistic 
and in the process achieve better performance. In PR0IXM3 cut 
is an example of such a primitive. When selected it succeeds 
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and as a side effect commits the interpreter to the choice 
of the clause in which it occurs and all the choices made 
for the literals occuring before it in the clause. As a 
result subsequent backtracking behaviour is modified. 
Another example is annotation of variables in IC-PROLOG 
CCM79], Using variable annotation one can define a dif- 
ferent order of evaluation for different usage of a clause. 
This can also be used for achieveing delaying of a literal 
in a resolvent until one or more of its variables are bound. 

Although using such control primitives increases the 
efficiency of inference it also makes the program less read- 
able and difficult to change. Morevover these attempts do 
not take us closer to the ideals of logic programming where 
logic component and control component are separate. 

2.3 External Control Separated From Program 

Separating the control component from the logic com- 
ponent improves program clarity and makes it possible to 
specify and modify control of the program without altering 
the logic component. This separation allows the user to 
express control at a micro level: for example control could 
be specified for a particular clause or a particular literal 
( i , e . local strategy ) alternately it could be global so that 
it is applicable to the whole search- space . The expression 
of control information in the form of meta-rules and meta- 
language was suggested by Davis CD80] and Gjiallaire [6L823 . 
These idesS are further improved and made concrete in Meta- 
log proposed by Dincbas and fiepape CDL84] . We have imple- 
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Biented the basic meta-level facilities given in Metalog for 
the logic programming shell VIDHI. 

2-4 Organisation Of Meta-Level Control 

In our implementation of the meta-control facility 
there are two distinct levels in which knowledge is 
expressed. 

(1) Obiect-Level ; Where object knowledge or domain 
specific knowledge for solving the problem is 
expressed. It represents the definition (’What’ kind of 
knowledge) or logic component of the problem 

(2) Meta-Level : Where meta-knowledge or control 
information about solving the problem is expressed. It 
represents the strategies or heuristics (’How to’ kind 
of knowledge) to be used in applying the object 
knowledge for solving the problem. 

Both object knowledge and meta knowledge are to be expressed 
in Horn Clauses using the same syntactic framework (a la 
Prolog) . Object knowledge is expressed by defining object- 
clauses (i.e. object-facts and object-rules) while meta 
knowledge is expressed by defining meta-clauses (i.e. meta- 
facts and meta-rules). A meta-clause is distinguished frcmi 
an object-clause by the presence of a meta-predicate in the 
consequent position. A meta-predicate is an action predicate 
which is pre-defined in the system and whose semantics is 
known to the intearpreter^ The terms of meta-clauses are 
clauses, resolvents and literals of object -knowledge. Thus 
through meta-clauses the user has access to the entire set 
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of clauses and the complete proof -tree. 

2.5 Operation Of Interpreter With Meta-Control 

2.5.1 In Absence Of Meta-Clauses 

In the absence of any meta-clause the interpreter 
chooses default strategy (i.e. the Prolog strategy ) 

(1) Choosing left-most literal in the resolvent 

(2) Choosing a clause in the textual order of clauses 

for resolution of the selected literal, 

(3) In case of failure systematic backtracking to the 

last choice made and trying next alternative. 

2.5.2 In Presence Of Meta-Clauses 

In the presence of meta-clauses, .control specified in 
the met a -knowledge is used in applying the object-knowledge 
to solve the problem. There are three main modules which can 
be identified in describing the operation of the interpreter 
with meta-control. 
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Th© top-level interpreter takes a goal that is to be 
inferred and activates the meta- interpreter at various deci- 
sion points in the inference. Meta- interpreter when 
activated, analyses meta-clauses during which it invokes the 
sub-interpreter for processing^ goals given in the antecedent 
of a meta-clause. When goals in the antecedent of a meta- 
clause succeed the interpreter acts according to to the 
meta-predicate present in the consequent position of the 
meta-clause. As a result the meta- interpreter constructs the 
strategy to be applied and the top-level interpreter applies 
it in inferring the goal. The sub -interpreter is a Prolog 
like interpreter with a pre-defined strategy mainly used 
for sub-processing of the conditions in meta-clauses. The 
goals occuring in the antecedent of a meta-clause are 
object-goals which are either user defined or system 
defined. 

2.6.3 Analysis Of Ifeta-Clauses 

A meta-clause which has meta-knowledge einbeded in it 
will essentially look like 

( <meta-predicate> <- <condl> <cond2> , . - <condn> ). 

Each metarclause is charcterised by some meta-predicate in 
its consequent position. These meta-predicates which are 
action predicates should occur only in the consequent posi- 
tion and no where in the body of the meta-clause. Meta- 
clauses are analysed by the meta- interpreter in the order; in 
which they are defined and depending upon the decision 
point attained by the top-level interpreter. The arguments 
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(i.e. terms) of the meta-predicates are clauses resolvents 
and literals from the object-knowledge. The types of the 
arguments of a meta -predicate are known to the interpreter 
along with the semantics of the meta-predicate. Once the 
condition on arguments of a meta -predicate is satisfied, 
evaluation of conditions in the antecedent of the meta- 
predicate begins. If the evaluation results in success then 
interpreter takes action corresponding to the meta- 
predlcate. Whereas if it fails the next meta-clause is 
tried. When all the meta-clauses are exhausted then the 
default choice is taken. 

2.5.4 Semantics Of Meta-Predicates 

The naive interpreter (i.e. one without meta-control) 
has three main decision points : 

(1) choice of the literal in a resolvent 

(2) choice of clause for resolution of the selected 

literal and 

(3) choice of backtracking point 

The selection of meta -predicates has been influenced by our 
intention of extracting these choices from interpreter and 
making them available to the user at the meta-level. In 
addition meta-predicates are also provided to inhibit the 
choice of a literal, clause or backtracking point. Syntax 
and semantics of meta-predicates are as follow; 
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Selection Of Literal 

(1) (activate <rslv> <lit> ) <- <condl> . . . <condn> 
activates literal <lit> in the current resolvent <rslv> 
if conditions in the antecedent (i.e. <condl> ... 
<condn>) are satisfied. 

(2) (freeze <rslv> <lit> ) <- <condl> . . . <condn> 
freezes a literal <lit> in the current resolvent <rslv> 
if conditions in the antecedent (i.e. <condl> 
..<condn>) are satisfied. 

Selection Of Clause 

(1) (chooseclause <lit> <body> ) <- <condl> . . . <condn> 
chooses the clause, for rsolution of the selected 
literal <lit>, whose antecedent is charcterised by 
<body> if conditions in the antecedent of meta-clause 
{<condl>. . <condn>) are satisfied. 

(2) (inhibclause <lit> <body> ) <- <condl> . . . <condn> 
inhibits the choice of a clause, for resolution of the 
selected literal <lit>, whose antecedent is charcter- 
ised by <body> if the conditions in the antecedent of 
the meta-clause ( <condl> . . <condn> ) are satisfied. 

Selection Of Backtracking Point 

(1) (backfall <lit> <rslv> ) <- <condl> . . . <condn> 
chooses a backtracking resolvent <rslv> in case of 
failure on literal <lit> if conditions in the 
antecedent of the meta-clause are satisfied. 

(2) (Inhibbaek <iit» <^ly> ) <- <condl> . . . <condn> 
inhibits the choice of backtracking resolvent <rslv> in 
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case of failure on literal <lit> if the conditions in 
the antecedent of the meta-clause are satisfied. 

In the meta-clauses as shown above the literals in the 
antecedent of a meta-clause are optional. In case they are 
absent it defines a meta-fact. 

Z.B Case Studies 

By judicious choice of control strategies the user can 
achieve significant improvement in the efficiency of infer- 
ence. We give here a few examples of meta-programming and 
describe some of the useful control strategies we have us^. 
The user can refer to the VIDHI manual [S863 for more 
details on syntax for defining clauses. It also has facili- 
ties for defining computational -predicates, question^rules 
(ask-user) and procpred etc. 


lUcaaiple ZJl A map is to be coloured with at most four 
colours such that no two 

adjacent areas of the map have the same colour . 


object-clauses 
(def assert exl-12 


(colour ?xl ?x2 ?x3 ?x4 ?x5) 


(nxt ?xl ?x2) 
(nxt ?xl ?x4) 
(nxt ?xl ?x5) 
(nxt ?x2 ?x3) 
(nxt ?x2 ?x4) 
(nxt ?x3 ?x4) 
(nxt ?x4 ?x5)) 



(defassert exl-1 (nxt red blue)) 
(def assert exl-2 (nxt red green)) 
(defassert exl-3 (nxt red yellow)) 
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<def assert exl-3 
(def assert exl-4 
(def assert exl-5 
(def assert exl-6 
(def assert exl-7 
(def assert exl-8 
(def assert exl-9 
(defassert exl-10 
(def assert exl-11 


(axt blue red)) 

(nxt blue green)) 
(nxt blue yellow)) 
(nxt green red)) 
(nxt green blue)) 
(nxt green yellow)) 
(nxt yellow red)) 
(nxt yellow green) ) 
(nxt yellow blue)) 


The object-facts in the database describe the occurence 


of colour in the adjacent areas. The object-rule defines the 


given graph. 


We have tried two control regimes and found it improves 
the performance in terms of number of resolutions carried 
out. The strategies which were imposed through meta-control 
were the following : 

Early Detection Of Failure 

The selection of literal to be resolved in the resol- 
vent should be such that the failures are detected quickly. 
If there is a literal which would definitely fail then 
choosing other literals merely delays this inevitable 
failure. This idea can be incorporated in the strategy of 
choosing a literal first which is totally instantiated, as 
choosing other literals will not change it. This strategy 
is expressed in the following meta-rule 


(defassert mex2-l (activate ?r (nxt ?x ?y)) 

. <- (totalinst (nxt ?x ?y))) 

It chooses a literal (nxt ?x ?y) in any resolvent if it 
is a totally instantiated literal. The predicate totalinst 
is a system predicate defined using defproc facility in 
■VIDHl CS863/' '' ■ . 
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Intelligent Backtracking 

The other strategy which we have tried is a form of 
intelligent backtracking. In this when failure is encoun- 
tered then instead of backtracking naively, backtracking is 
done to the resolvent which does not contain any instance of 
failed literal. This can be expressed by the meta-rule 


(def assert mex2-2 (backfall ?p ?r) 

<- (not (in ?pl ?r) (subsume ?p Tpl))) 

(def assert il (in ?x (?x . ?y))) 

(defassert i2 (in ?x (?y . ?z)) <- (in ?x ?a)) 


The literal subsume in the antecedent of meta-rule is 
defined using defproc facility in 7idhi. A complete trace of 
the deduction using these meta-rules is given in the appen- 
dix . 

performance of meta-control 


(30AL : (colour ?xl ?x2 ?x3 ?x4 ?x5) 

R : no. of successful resolutions 

B : no. of backtracking points. 



without meta-control 

with meta-control 

R 

20 

(mex2-l) 

9 

B 

13 

1 

R 

20 

(mex2-2) 

11 

B 

■ 13 

1 
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Example 2_2 This is the problem of reversing a list 
objeot-olaases 

(def assert ex2_l (rev nil nil)) 

(def assert ex2_2 (rev (?x . ?y) ?z) 

<- (rev ?y ?t) (app ?t (?x) ?z)) 


(def assert ex2_3 
(def assert ex2_4 


(app nil ?x ?x)) 

(app (?x . ?xs) ?y (?x . ? 2 s)) 
<- (app ?xs ?y.?zs)) 


We observe that whenever the first argument of the 
literal rev is a variable and the second one is instantiated 
(i.e, (rev ?x (1 2 3))) then ex2_2 is applied and it gen- 
erates the rev goal with both arguments as variables. These 
are bound to nil and then app goal is tried. If app does not 
succeed then it backtracks and resatisfies the goal rev. 
This way it keeps going on till the length of first argument 
in the original rev goal becomes equal to the length of the 
second argument. This unnecessary backtracking can be cut 
down by activating app goal in the resolvent before the rev 
goal . This idea can be expressed by either of the following 
meta-clauses : 

( def assert ia©x2._lC|tdt ivatjs ?r (app ?x ?y ?z))) 

(def assert mex2_2 (freeze ?r (rev 9x fy)) 

<- (var ?x)) 



22 


X>erfox»axice of »eta-control 

GOAL : (rev ?x (123)) 

R ■•no. of successful resolutions made 
B : no. of backtracking points. 



without meta- control 

with meta-control 

R 

14 

10 

B 

4 

0 


Example 2_3 This is the problem of finding whether two 
trees have same sequence of leaf -tags, 
object -clauses 

(defassert ex3-l (same-leaves ?tl ?t2) 

<- (leaves ?tl ?1) 

(leaves 7t2 71) ) 

(defassert ex3-2 (leaves (leaf 7x) (?x))) 

(defassert ex3-3 (leaves (tree (leaf 7x) 7t) (7x . 71)) 

<- (leaves 7t 71)) 

(defassert ex3-4 (leaves (tree (tree 711 ?lr) 7r) 71) 

<- (leaves (tree 711 (tree 71r 7r)) 71)) 

To find whether two trees have the same sequences of 

leaf -tags, goal (same-leaves <treel> <tree2>) is executed. 

It matches with the rule for same- leaves and generates two 

leaves literals. The first leaves literal generates leaf- 

tags for the first tree and second one tests whether the 

tags generated are same as those of the second tree. In case 

of failure, generation of complete sequence of leaf -tags by 

first leaves literal is felt unnecessary. Instead, if the 

tags are tested as ahd when they are generated rather than 
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waiting for the complete generation, failure will be 
detected much faster. This is achieved by having co~ 
routining between the two leaves literals. The following 
meta-control expresses this strategy : 


(def assert inex3-l (activate ?mr (leaves ?mx (?mu . ?mv))) 

<- (atom ?mu)) 


performance of oieta-control 


GOAL ; (same-leaves (tree (leaf a) (leaf b)) 

(tree (leaf b) (leaf a))) 
K : no. of successful resolutions 

B : no. of backtracking point 



without meta-control 

with meta- control 

R 

3 

2 

B 

4 

3 


Sxaiaiple Consider a family databse describing father 

and grand-father relations. 


object-clauses 


(def assert al (father a b)) 

(def assert a2 (father a c)) 

(def assert a3 (father b d)) 

(def assert a4 (father be)) 

(def assert a6 (father d h)) 

(def assert ad (father d i)) 

( def assert a7 ( father c f > ) 

(def assert a8 (father eg)) 

( def assart a9 (father f j)) 

(defasseft al0 (father f k>) 

(def assert rl (gr-father ?x ?y) <- (fa ?x ?z) (far ?z ?y)) 
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As we have seea in the chapter 1 how the gr-father goal 
in which first argument is a variable generates unnecessary 
failure branches. To overcome this we need to change the 
order of literals in the rule for gr-father such that it 
does not affect the computation of other goal. This is 
expressed in either of the following meta-clauses • 


<def assert ml (freeze ?r (father ?x ?y)) 

<- (var ?x) (var ?y)) 

(def assert m2 (activate ?r (father ?x ?y)) 

<- (atom ?y)) 


performance of meta-control 


■GOAL : (gr-father ?x k) 

R : no. of successful resolution 
B : no. of backtracking points 



without meta-control 

with meta-control 

R 

9 

3 

B 

6 

0 


Remark 

In all the examples meta-control gives better perfor- 
mance in terms of reduced number of resolution and back- 
tracking points. However, improvement in performance is at 
the cost of certain overheads involved in sub-processing of 
condition in meta-clauses. At every decision point meta- 
clauses are analysed and goals in the body of Bieta-plauses 
are satisfied. Thus meta-control cuts down the search-space 
of the problem by introducing search in the search-space of 
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sub^problets . Th© meta-con'brol is specially advantageous when 
seroh-space of the sub-problem is smaller than that of the 
problem which is to be solved. 

2.7 Implementation 

Implementation of the meta-control facility was done 
in clisp environment on top of Franz Lisp. 

2.7.1 Bepresentation Of Database 

The representation scheme for object -knowledge database 
and meta- knowledge database is same. Syatax for defining a 
clause (object-level or meta- level) is as 

(def assert <cls-name> <consequent> <- <antecl> . . . <antecn> ) 
which is same as the syntax for defining a clause in Vidhi, 
The literals in consequent and antecedent of the clause look 
like 

( <predicate-namo> <argl> <arg2> . . . <argn> ). 

Object facts and object rules are stored as property of the 
atom <prodioate-naa©> under the attributes facts and rules 
respectively. Meta-olauses are stored as property of the 
atom $meta under the attributes $chlit, $chcls and $bt 
depending on. which meta-predicate is occuring in the meta- 
clause. 

2.7.2 Bepresentation Of The Environment 

The environment is stored as an association . list of 
variables and their bindings. All the variables in the 
clause are renamed when the clause, is selected for resolving 
the ohoseh literal , Renaming of variables ensures that vari- 
ables in the clause are different from those occuring in the 
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goal. Each entry in the stack, which corresponds to one 
inference cycle in the deduction of the goal, contains an 
association list of variables instantiated till that step. 
2.7.3 Inference 
2.7.3.]- Data Staructuire 

The data structure ohosen for implementing the infer- 
ence mechanism in the interpreter with meta-control is the 
stack. An iterative algorithm for inference is implemented 
so that at any step the complete proof -tree is accessible. 
Each entry in the stack corresponds to a activation record 
containing object-information (obj-info) and meta- 
inf ormation ( meta- inf o ) . 

Obj-info is alist of five elements which looks like : 

( <query> <qlist> <f acts> <rules> <alist> ) 
where <query> is the literal chosen in any step from the 
current resolvent <qlist>. The <facts> and <rules> are the 
facts and the rules that remain to be applied for solving 
the literal <query>. The last element in the obj-info is the 
association list of variables till that step. At any time 
when inference is proceeding in the forward direction, the 
entries corresponding to <query>, <facts> and <rules>, in 
the top activation record, will be $quejry $facts $rules 
respectively. As and when the decisions about the choice of 
literal and clause are made, the entries $query, $faots and 
$ruies are suitably substituted. 

The second entry in the activation record includes , the 
Information about meta*clauses (i.e. meta- info). It is a 
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list of three element which looks like 

( aeta-clauses~for-choosing- literal 
meta-clauses“for-choosing-clause 
raeta-clauses-f or-choosing-bt-point ) 

Depending upon which decision is to be made in the inter- 
preter, the corresponding meta-clauses are analysed and 
meta-information is updated, so that on backtracking the 
remaining meta-clauses can be tried. 


2. 7. 3. 2 Data Structure Definition 


Each entry in the stack as described above is defined 
as a Lisp Structure. It is advantageous to do so as it pro- 
vides appropriate definition of constructor and selector 
function. 


(def struct (entry (‘.constructor make-entry (obj-info 

meta-info) ) ) 

obj-info 
meta-info ) 

(def struct (obj-info (: constructor make-obj-info (query 

qlist 

facts 

rules 

alist))) 

query 

qlist 

facts 

rules 

alist) 

(def struct (meta-info (‘.constructor make-meta-info 

(chlit-rules 
chcls-rules 
bt-rules ) ) ) 

chlit-rules 

chcls-rules 

bt-rulas) 



28 


2 . 7 . S . 3 Wojc Meta “Control 


INPUT : Input to the interpreter is a goal (list of 

literals} i«e. ^list that rs to be solved* 

;* qlist is renamed and literal (next) is to be added 
i ^ at the end . / 

initialisation of stack / 

;* in the begining alist is nil / 

(let ((ini~stack (make-entry (make-obj-inf o ’$query 

qlist 
’$facts 
‘ $rules 
nil) 

( make -met a- inf o 

( get-chl it-rules ) 

( get-chcls-rules ) 

( get-bt-rules ) ) ) ) ) 

;* get-chl it-rules, get-chcls-rules, get-bt-rules 
;* are functions for getting meta-clauses for 
;* choosing literal, clause and backtracking 
; ♦ point respectively. 

;* TOP-LEVEL ITEBATION 
; * initialisation of iteration variables 

(do* ((stack ini-stack) 

(top-stack (oar stack) (car stack)) 
(obj-info-lcl (entry-obj-info top-stack) 
(entry-obj-info top-stack) ) 
(meta-info-lcl (entry-meta-info top-stack) 
(entry-raeta-info top-stack) ) 
(qlist-lcl (obj-info-qlist obj-info-lcl) 
(obj-info-qlist obj-info-lcl)) 
(alist-lcl (obj-info-alist obj-info-lcl) 
(obj-info-alist obj-info-lcl)) 
(over-flag nil)) 

((or (null stack) over-flag) 

;* Termination Condition for Top-Level 
;* iteration. 

(oond (over-flag t) 

(t ’$fail-infer))) 

j* Body of the TOP-Level iteration begins here / 

(cond ■ ’ . : . 

,'* sub-problem is solved./ 

;* This arises when the argument of nesation 
;* is succeeded. / 

(setq over-flag t)) 
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(t 

;♦ Inference cycle with the top-stack begins here/ 
;♦ Fiysti decision that is to be made is about the 
;* choice of literal in the resolvent / 

This choice is exclusive and not reconsidered 
;♦ upon backtracking / 

;* It calls meta-interpreter for choice of literal 
The argument given to it are obj-info and 
;* meta-info / 

(apply-chlit-rules obj-info-lcl meta-inf o-lcl) 

,* It analyses meta-clauses for choosing literal 
in the resolvent / 

;♦ The chosen literal is substituted in place of 
;* query / 

(let {{ query (obj- info- query obj-info-lcl))) 

;* solve the query / 

If query succeed then update top-stack 
and create new top- stack / 

If query fails then call meta- interpreter 
; * for choice of backtracking point / 

(cond ( ( it-is-a-non-database-query ) 

Its a non-database query / 

It could be any one of these 
not, =, ask-user, defcomp, defproc, 

;* cut, next etc. 

{ let ( ( res ( solve-the-query query ) ) ) 

(cond ((not (fail-p res)) 

query succeeds / 

(modify top-stack)) 

(t 

query has failed / 
call meta- interpreter for 
choosing bt point / 

(setq stack ( apply-bt-rules stack)))))) 

(t 

Its a database query / 

Call meta- interpreter for choosing a 
clause for resolving the literal query / 

;* ITERATION for choosing a clause / 

Initialisation of Iteration variables 

(do ((clause (rename-vars (apply-chols-rules obj-info-lcl 

a^a-inf o-lcl )) 

(rename-vars (appl’y-chcls-rules obj-info-lcl 
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(Icl-res 


meta-inf o-lcl ) ) ) 

(unify query 

(asrt-conseq clause) 
aliat-lcl) 

(unify query 

(asrt-conseq clause) 
alist-lcl))) 


((null clause) 


; * TERMINATION condition for iteration / 
All facts and rules are exhausted so 
”, * call meta- interpreter for choosing 
a backtracking resolvent / 


(setq stack (apply-bt-rules stack))) 

;Hc body of Iteration for choosing a clause 

(cond ((fail-p Icl-res) 

Chosen clause did not unify / 

’ skip-and-try-other-clause ) 

(t 

Chosen clause has unified / 

(modify-current-top-stack) 

( create-new-top-stack ) 
(return))))))))))) 


2 . 8 CcKnoluslon 

We have implemented meta-control facility and found 
that the combination of object and* meta level (i.e. 
knowledge and meta-knowledge) gives to a system more natural 
and i^werful control expression facility. Through the con- 
trol specified at meta-level, the user can define his own 
strategy and heuristics explicitly and more eleg€utitly. The 
powerful set of meta-clauses allows user to intervene on the 
process of dedwctioh ah<I guide the search for a solution. As 
a result better i^rformance is achieved which is evident by 
the examples. 



3.ItmCTl(MliAL HSLATIOeiS IN LOGIC FROGRAISIING 
3 • 1 ¥tiQO'LIoi)iAX RAXA'bio&8 In Logic Pnognans 

In general, a predica'te in a logic program describes 
the relation among its arguments. It is found that very 
often these relations are functional in nature. For example 
consider the predicate mother with two arguments mother (X,Y) 
describing the relation " X is the mother of Y We say 
that first argument X is the function of the second argument 
Y as Y uniquely determines X. Thus the arguments of predi- 
cate mother are functionally related. Formally a functional 
relation f is said to exist among the arguments of a predi- 
cate p, if a set of arguments in positions I of p uniquely 
determines a set of arguments in positions D of p. It is 
described as 

f : I -> D for predicate p. 

Further the predicate p is termed as a predicate with fvinc- 
tional dependency or fd-predicate and sets I and D are known 
as the set of independent and dependent arguments of p 
respectively. 

In a logic program P an fd-predicate say mother (X,Y) 
(where Y is the independent and X the dependent argument) 
suggests that there do not exist three terms u , v and t 
such that V ^ t and mother (v,u) and mother (t,u) both are 
logical consequences of P. In addition to this, the func- 
tional relation information (fd- information) corresponding 
to an fd-predicate is applicable to the >diole search-space 
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of the inference irrespective of the search- strategy used. 
Hence the specification of fd-infoxmation is global to. the 

database and does not disturb the declarative nature of the 
logic program. 

3.2 functional -Ccoputation in Logic Programming 

3.2.1 Functionality vs Detenalnacy 

The notion of functionality in a logic program is quite 
close to the notion of determinacy. Every deterministic com- 
putation is essentially functional in nature. The notion of 
deterministic computation suggests that it would succeed at 
most once giving a unique answer. But the notion of func- 
tionality says that it would always give unique answer(s) 
though it may succeed more than once. The ex 2 uaple which 
distinguishes these two notion is given as follows 

Ixaapie 3_1 Consider the following clauses 
t(X.a). 

t(X,Y) <- t(X,Y). 

Here the predicate t is an fd-predicate in which the first 
argument uniquely determines the s.econd. For a given value 
of first argument it computes a unique second argument. This 
computation although functional, for it produces a unique 
answer, is not deterministic as it can produce this answer 
infinite number of times. 

The notion of determinacy is described by Nakamura 
CN063 at a logical «md an operational level. Our notion of 
functionality ia ad that of logical determinas;^ . 
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3.2.2 Ito‘t*oxMl.itis1flc'*'CkxBpu'ta1;loii in Logic PirograBiBting 

uiAln purposQ of making a logic program dcterminis" 
t>ic is “fco reduc© t-h© search~spac© for th© compu'ta'tion of a 
goal. This improves th© performance in 'terms of ©xecu'tion 
t>im© of “the goal and space reg.uiremen't on "the run 'time stack 
of the interpreter. The main tool available for making a 
logic program deterministic is cut ( ! ) . This is used to 
prune the fruitless paths in the search-space. When selected 
it succeeds and commits the interpreter to all choices made 
since the parent goal is unified with the head of the clause 
in which it occurs. For more elaboration on operational 
details of cut one may refer [CM843, [SS863. The computa- 
tion described in Example 3_1 can be made deterministic by 
introducing out in the first clause as 

t(X,a) <- I. 
tCX.Y) <- t(X,Y). 

Now the program produces unique answer for a given value of 
first argument only once. 

3.2.3 Cot And Functional-Ccnaiiutations 

The cut, although very powerful in its ability to prune 
search-space, offers some disadvantages as many of its uses 
can only be interpreted prooedurally [SS863. It is assym- 
metric as it prunes the clauses occuring below the clause in 
which it occurs and not the clauses above it. Moreover it 
affects the behaviour of clause in which it occurs irrespec- 
tive of how the clause is being used in the inference. This 
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would become clear in the following example. 

E xample 3^2 Consider a logic progreuo for appending two 
lists. 

append([3,Y.Y). 

append(CX|Xs3,Y,CX!Zs3) <- append(Xs,Y, Zs) . 

Consider the goal append{ [1,2] , [3,4] .Answer) . The computa- 
tion performed by above goal is functional in nature as Y 
oan be determined uniquely. But it is not deterministic 
beoause upon baoktraoking it would try second rule which 
remains to be applied. To overcome this we make it deter- 
ministic by introducing cut as 

append([],Y,Y) <- 1. 

appead(CX{X83,Y,CXjZs3) <- append(Xs,Y,Zs) . 

This no doubt solves the above problem but introduces 
another problem. Now the goal apppend(X,Y, [1,23) which is 
not functional at all also has a deterministic solution i.e. 
X = [3 , Y = [1,23 

Although, using cut, enables functional -computation in a 
logic program, it may make other computations deterministic 
which are not functional in nature. Thus cut can not handle 
the problem of ' functional computations. This problem is 
mainly due to cut occuring in the clause for making the c<Mn- 
putatioii detexministio. On the other hand functional rela- 
tion information is specified for a predicate and it is glo- 
bal and declarative in nature. 
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3.3 li:it«n»ret«r With Fd-InfoiMtxoa 

A» disoussed in the previous section, cut does not pro- 
vide A right solution to the problem of performing 
funotionAl-computstlon deterministically. Ihe existing logic 
programming framework, although very powerful in its ability 
to simulate non-determinism, is found to be quite expensive 
when it comes to the problem of performing functional - 
computation. Horeover there is no way of specifying fd- 
information relevant to a logic prograun. We offer a solution 
to the above problem by proposing a logic programming frame- 
work in which 

(1) it would be possible to specify functional relation 
information in terms of fd-predicates in the program. 

(2) the interpreter would make use of such functional 
relation Information and eliminate unnecessary recomputa- 
tion by making the computation deterministic according to 
the functional relation information. 

3.3,i Terminology 

i 

In this section we introduce some terminology which we 
have used in describing our algorithm and its implementa- 
tion. For details on syntax of defining clauses and posing 
query etc. one may refer to VIDHI [S86]. A summary of basic 
oooanands is also given in APPENDIX 1. 
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Tho functional irelation information corresponding to a 
fd predicate can be specified in Lisp like syntax as 

(deffd < <pred-name> <argl> <arg2> ... <argn>)) 
where <argi> for 1 <= i <= n is any of the following 

i : if <argi> is an independent argument 
d : if <argi> is a dependent argument 
X 5 if <argi> is neither an independent 
nor a dependent argument 
(i.e. a dontcare argument) 

Tho fd^information corresponding to the fd-predicate (temp 
?pos ?temp)t whore the first argument ?pos uniquely deter- 
mines the second argument ?temp, can he represented as 
(deffd (temp id)). ' 

At any time during the inference, if there is a literal 
which is an fd-predioate then a variable occupying 
Independent/dependont/dontoare argument' position of the 
literal Is known as an independent/dependent/dontcare vari- 
able w,r,t. soae functional relation. 

for mabing use of the functional relation in the infer- 
ence, it is ii^rtant to determine whether a particular 
functional relation is applicable to the computation of a 
goal. If all the independent argument position w.r.t. the 
functional relation in the literal are ground terms then 
that functional relation is said io be applicable to the 
literal.' " • " 

A goal literal p is said to succeed totally if either . 
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( 1 ) is a fact <i in "tha da'tabasa sudi bhab p unifies 
*fith q or 

(2) trhere exisba a rule r in the database such that p uni- 
fies with head of the rule and all literals in the 
antecedent of r succeed totally. 

As the inference proceeds, the relevant fd-information 
is accessed and stored as passive-dependency-infonnation 
(passive-dpd-info) and active-dependency-information 
( act ive-dpd- info). The functional information is usually 
passed through the passive-dpd-info into active-dpd-info. 
The functional information in passive-dpd-info euad active- 
dpd-info is kept in the form of a pair of list of dependent 
arguments and corresponding fd-predicate. In an inference 
cycle, if a literal selected for resolving, say p, is an 
fd-predicate then fd-information applicable to that Instance 
of the literal is added to the passive-dpd-info present in 
the system. When the literal p succeeds totally then all the 
fd-information corresponding to p present in passive-dpd- 
info is moved to active-dpd-info present in the system. At 
any time, all the information present in the active-dpd-info 
is active in the system and affects the ccamputation of sub- 
sequent goals. 

The presence of functional-relation information modi- 
fies the backtracking behaviour of the interpreter and as a 
result helps in eliminating unnecessary recom^tation of the 
goal, l^en there are no functional relations specified in 
the program then in the event of failure the interpreter 



- 38 - 


porfoms naivo baoktracking which means going back to the 
last daoision point in the search~tree and re~satisfying the 
goal by taking next alternative. Whereas, if fd- information 
is present then a literal may be restricted against back" 
tracking. If a literal is restricted against backtracking 
then during backtracking the literal is not re-satisfied by 
trying next alternative. The idea of restricting a literal 
against backtracking can be illustrated as follows : 

Consider a resolvent R, at any time in the computation 
of a goal as 

R *. <litj^> .. <lit^^j>,<litj.>,<lit^^j^>, ..?;litj^> 

Suppose first i-1 literals succeed and literal <litj^> is 
restricted against backtracking then in the event of future 
failure and subsequent backtracking the literal <litj^> is 
not re- satisfied. 

In every inference cycle, a literal is chosen frcai the 
resolvent. The chosen literal is unified with the head of 
the clause for the literal. If the unification succeeds 
then it returns an association list containing the updated 
bindings of the variables. If the unification fails then it 
does not merely return the failure but also returns the 
argument number of the literal where failure has occured and 
the variable (if any) due to which failure is occuring. 

In case of failure on a literal, actiVe-fd-info is con- 
sidered in making a decision about backtracking-point. This 
idea will become clear by the following illustration : 
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Lot thoro bo o rooolvont R given as 

Suppose, as the inference proceeds, literals <litj^> to 

succeeded totally. Let a literal <litj> be an 
fd~predioate nith some functional relation applicable to it. 

If litoral <litj> unifies with head of some clause then the 
corresponding functional relation information is added to 
passive -dpd- info present in the system. Further, if it 
succeeds totally then the corresponding functional informa- 
tion is moved from passive-dpd-info to active-dpd-info.Now 
latter, if literal <libj^> fails such that failure is over 
some of the dependent arguments of the literal <litj> then 
Instead of backtracking to the literal <litj^_j^> it back- 
tracks to the litoral <litj^j>. This is what is known as 
setting the backtracking point. If the failure of tJae 
literal is not over any dependent argument in active-dpd- 
info then backtracking is as usual. 

3.3.2 Algoritlai for The Interpreter 

The algorithm for the interpreter using functional 
relation information ^is given in simple terms as follows : 

Data Structure 

# , 

The interpreter uses a stack- Each entry in the stack 
corresponds to one inference cycle containing the following 
Information t 

qlist i 'itVis' ;'\refblV€«fit ■■’'oontainlng' literals' ' 
which remain to be proved. 
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facts : all the facta corresponding to the first 
literal in the qlist. 

rules 5 all the rules corresponding to the first 
literal in the qlist. 

allst : association list containing the bindings 
of the variables till that point in the inference, 
a-fd-info : association list containing active 
functional relation information and corresponding 
f d-predicates . 

p-fd-info association list containing passive 
functional relation infoimation auad corresponding 
fd-predioates. 

In each inference cycle, first literal in the resolvent 
is solved. If success occurs then information on the top-- 
stack is updated and new top-stack is created which is 
pushed on the stack. If failure occurs then top-stack is 
popped out and inference is continued. 


IHFOT : goal which is a list of literals to be solved i.e 


qllst. 


Initiaiisatioii Of Stack _ 

top-stack <- ( qlist _ 

* <all-faots~fcr (first-of qlist)) 
#»ll-rules-for (first-of qlist)) 


nil 
nil" .. 
nil > 


stack <- (top-stack) 

, f , 
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Top-iwovol It«r4itl<m 

; ♦ for on® Inf orono® ojp^oX® it goes through the loop 
i* ono®. 

KEEP RSPSATZNQ 

1. If staok i® enqpty then return failure 

2. If qliet i® ®iipt 7 then 

i 

2.1 print the answer 

2.2 if (nor® answer required) then 

{ 

(pop the stack) 

( top-ataok < - { f irst-of stack ) ) 

1 

els® 

{ 

return 

} 

} 

els® 

;* qllst is non-eapty 
;* carry out the inference 

{ 

;♦ ITEBATION for CBOOSIHa k CLAUSE 
Initialisation 

query <- <first-of qlist) 

qliet <- resolvent or goal to be solved 

in the activation record on 
top of the stack; 

rule»-to-try <- clause® for the query 

jrule <- (first-of rwles-to-try) 

;* If the head of the clause unifys with the 
;# query then backtracking over query in. case 
;* of future faij-ure is decided. 

;♦ If unification fails then backtracking 
;k point is set and it is decided 
;k whether to try next available rule 
;* or backtrack. 

if (query unifies with the 

head of the rule) then 

if (and (query is an fd-predicate) 

(inhere is a aon'"nil fd^reiation 
whic^ can b® applied to the 
query)) then 

{ 

if (unification instantiates only 
dependent arguments ) then 

1 . restrict query against backtracking 

2. create new top-stack 
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3. push new top-stack 

4. top-stack <- <first-of stack) 

else 

does not instantiate only dependent 
;* arguBient. 

;* usual backtracking 

1 . create new top-stack 

2. push new top- stack 

3. top-stack <- (first-of stack) 

} 

) 

else 

i* query is not an fd-predicate 
or fd-relation is nil 
;* usual baoktraokins 
{ 

1. create new top- stack 

2. push new top-stack 

3. top- stack <- (first-of stack) 

} 

} 

else 

query does not unify with the head 
;* of the rule./ 

if there are active dependencies 
;* then set backtracking point 

i* if query is an fd-predicate and 
cause of failure is dpd-variable 
;* or dpd- argument then check for 
oentradiotion 

;* if oontradiqtion is found then 
;» bacSrtiraok otherwise try-next-rule 
{ 

l.if (aotive-dpd-info present) then 

{ . 

if (failure violates active-dpd-info) 

then 

{ 

set backtracking point 

} 

2. if (and (query is an fd-predicate) 

(there are non-nil dpd-arguments ) ) 
then 

if (failure due to dpd-argument or 
dpd-variable) then 

if (contradiction) then 
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{ 

BACKTRACK 

} 

els® ;* not a contradiction 

{ 

TRY-NEXT-RDLE 

) 

} 

else 

;* failure not due to 

;* dpd-variable or dpd-argument 

i 

TRY-NEXT-RULE 

} 

} 

else 

;♦ not an £d-predicat© 

{ 

TRY-KIXT-ROLE 

} 


> 

) 


Ck>irreotaess-Be«nlt 

The oorreotness of the algorithm described above is 
shown. The terminology »8«d in the proof la the standard one 
and oan be referred in Cb843.0ur intention in the proof has 
been to show that given a logic program, a goal computed by 
the algorithm is logical consequence of the program and in 
aooordano# with the fd-infomation specified by the user. 

Theorem : Let P be a logic program and g a goal. Let 
interpreter be as specified in the algorithm. The 0 be the 
answer- substitution (it has bindings of some or all of the 
variable# appearing in the goal) obtained in the computation 

of the goal. : : 



Then gO in the logical consequence of P, 0 is con- 
sistent if.r.t. fd-'lnforaatlon specified in the program (i.e. 
all dependent variables In 0 are uniquely bound) and algo- 
rithm gives all possible an^ifer substitutions. 

Proof : CASK 1 


There are no functional dependencies specified in the 
system. This part of the proof is standard proof for the 
logic programnlng interpreter and can be referred in [L84}. 


Let g be the goal given as 
^ • « . • • I A |y and 

^1 * ^2 * • • • • » 

be the sequenoe of substitution obtained in each inference 
cycle in the computation of the goal g. 

To show that 

^ ( ^^ 1 * * * * 

is a logical consequence of P. 

The proof is by induction on the length of proof-tree 

of g. 

(1) suppose n = 1 <BASE CASE) 

a> g is a goal of the form <- and 

program has a unit clause of the form A <- 

such that 

Aj^ 0| a A Oj. 

Since A^ Pj is an instance 

of the unit clause of P, it follows that 

^ (A| 0|X » logical.' 
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cons«quenoe of P. 

(2) (INDUCTION HYPOTHESIS) 

AsBumo that roault holds truo when g is computed 
by tha algorithm with the proof-tree length (n-1). 

Suppose Oj, . . . ,Ojj be the sequence of 
substitutions used in the computation of g with 
proof length n. 

Let A <- (q >s o) be the 

first input clause and Aj^ be the selected literal 
of g suoh that 
A 0^ A^ 0^. 

Then by induction hypothesis 

^ ^ 2 * * * * * ^1 * * * 
is the logical consequence of F. 

If q a 0 then it is trivial, as Aj^ is an instance 
of fact in the database. 

If q > 0 then 

¥• ((Bj ... Bq^) Oj^ ... 0 ^) is 
logical oonsequenoe of P. 

a> ¥ (A Oj^ ... Oj^) is a logical consequence of P. 
=> ¥ (A| 0| ... Ojg^) is a logical consequence of P. 
a> ¥ ( (A^ • . . A^) 0^ ... 
is a logical oonsequenoe Of P. 

CASE 2 

The fd-inforsiation is specified in the system. 
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L«t s b« th« goal «iv®n as <- A^,. .. Aj^ and 

Oj 0^ ba tha aaquanoa of aubatitutions 

obtalnad in aach infaranoa oycia In the 
coaputation of tha goal. 

To 8ho«f that 

¥ ((Aj ... Aj^) Oj ... 0^) is a 

logical oonaaquanoa of P and substitution 0 is consistent 
w.r.t id’-lnfomation apaolfiad in the system. 

Tha proof is by induoion on the length of proof-tree 
for tha oonputation of goal g. 

(1) Suppoaa n = 1 ^BASE CASE) 
s> g is tha goal of tha for® <- A^. 

Lat f ba tha fd-infomation applicable to the goal 
g and progra® P has unit olausas of the form 



^p4 

such l^t Aj^ 0^ s Aj^ Oj for some m, l<=m<=j 

BmmtU » In the interpreter baaed o® the algorithm 
clauses for a literal ai'e oho^n aceoxding to their 
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textual ordor. 

= > Thara doas not axiat any substitution Oj^ 
such that 

* ^px \ 

for all X. 1 <s X <= a-l. 

Furthar nona of tha olauaes (1 <= x <= m-1) 

In tha prooaaa of failing, find that the goal 
<- Aj has any information contrary to f 
(i.a. literal A and differ only in some 
dependant argument corresponding to f). 

Remark : If there exists some contrary information 
then it mould not try remaining clauses. 

Since A. ., ,,,. 0. is an instance of the 
pm X 

unit clause of P therefore V (A^ 0^) 
is a logical consequence of P. 

ItiDOCTIOH IIYPOniESlB : 

Let the result hold true when g is computed by the 
algorithm with the pjsoof-tree length (n-l). 

Suppose 0j^****0jj^ sequence of 

substitutions used in the o<»p»tation of g with proof 

length n. Let A^ be first literal selected 

and let I be the fd- information applicable to 

Aj. Let the program have the clauses for A^ as 

follow ! 
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Ediaark *• In the interpreter based on the algorithm 
clauses are chosen according to their textual order. 

Let a clause chosen be 

^pm ®pinl ’ ’ * ■ ’ ®pmq 
such that 

0. = A- 0- 

pdi X 11 

This implies that for clauses A <- ...where 
I <= X <* m-l, one of the following cases hold true 


^0AS8 1 


There does not exist a substitution 0 such that 


°x 




(unification with the head of the clause falls). 

But failure does not indicate that A^^ has 
information which is contrary to the fd- information f. 


CASE 2 


(Unification with the head of the clause is successful) 


There may exist 0^ such that 

A 0 = A. 0 

px X 1 X 

* 

then either of the two cases would happ^ 
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(1) antecedent of the rule is not proved i.e, 
^ (B 


pjcl ' 




logical consequence of P. 

(2) There occurs a failure ahead i.e. 

( Ag . . . Aj^ } 0^ ... Og . • ) 

is not logical consequence of P 


When A| succeeds totally then f becomes active- 
fd** information in the system. Although there is failure 
ahead but it does not indicate that a literal A^^ 
for 2 <= 1 <= h (literal which is failing) has any 
information contrary to the fd-info3nnation f. 

Thus by induction hypothesis 

«?«1 *2 V > 

is a logical consequence of P and 0 is consistent 
w.r.t. fd- information f. 

= > If q > 0 then V ... 0^^ . . . 0^ 

is a logical consequence of P 

=> (A^„ 0, ... 0„) is a logical 
PIB 1 Xi 

consequence of P. 


=> V (Aj^ ... 0^) is a logical 
consequence of P. 


= > ¥ ((A^...,Aj^) 0^ ... Q^) 

is a logical consequence of P and substitution is consistent 
w.r.t. fd-information specified in the system. 
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(1) antecedent of the rule is not proved i.e. 

^ • ' * ^px<i ^ not 

logical consequence of P. 

(2) There occurs a failure ahead i.e. 

^ ^2 * ’ * ^ • • • O 2 • • ) 

la not logical consequence of P 

When succeeds totally then f becomes active- 
fd-information in the system. Although there is failure 
ahead but it does not indicate that a literal A^^ 
for 2 <= 1 <= k (literal which is failing) has any 
information contrary to the fd-information f. 

Thus by induction hypothesis 

^ " ?mq *• -^2 •• ^n ^ 

is a logical consequence of P and 0 is consistent 

w.r.t. fd~ information f. 

= > If q > 0 then V (B ... B„) 0, . . . 

mi mq 1 n 

is a logical consequence of P 
=> (A__ 0, ... 0 ) is a logical 

pin 1 Ti 

consequence of P. 

= > ¥ (Aj ... 0^) is a logical 
consequence of P. 

-> V Oj ... 0 ^) 

is a logical consequence of P and substitution is consistent 
w.r.t. fd-information specified in the system. 
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3.4 l«pl««M»itatlos 

A faoili'ty for specifying fd-inormat-ion and an inter- 
pre'ter which makes use of functional information in the 
inference process has been implemented in the clisp 
environment available on top of Frans Lisp on Unix. 

3.4.1 Bepresentation Of 0atabase 

The facts and rules corresponding to a logic program 
are defined using the facility for defining assertions i.e. 

(defassert <asrt“naffie> <conse<a> <- <antecl> ... <antecn>) 

This is same as the syntax for defining assertion in VIDHI. 
For more details on syntax for defining assertions, computa- 
tional predicates, and procpreds one may refer to manual for 
VIDHI CS88] . Each literal in the consequent and the 
antecedent of the clause looks like 

(<pred-name> <argl> .... <argn>) 

The facts and rules for a predicate are stored as property 
of the atom <pred-name> under the attribute facts and rules 
respectively. For resolving a literal chosen in the resol- 
vent in any inference cycle, first the facts are tried and 
then the rules. The facts and rules are stored in the order 
in which they are defined. 

3.4.2 Representation Of Environment 

The environment at any step in tl^ inference, is stored 
in the form of an association list of variables and their 
bindings. All the variables in a clause are renamed when the 
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clause is chosen for resolving the selected literal so that 
variables in the clause are different from all the variables 
in the resolvent. The association list in any inference 
cycle contains the variables bound till that point in the 
Inference. 

3.4.3 Bepresentation Of Fd-InforB»tion 

The fd- information corresponding to a predicate can be 
specified as 

(deffd < <pred-naiae> <argl> ... <argn>)) 

where each <argi> for 1 <= 1 <= n could be any one of the 
following ; ^ f 

i ; if <argi> is an independent argument 
d ; if <argi> is a dependent argument 
X : if <argi> is neither an independent nor 

a dependent argument. 

The fd-information so specified is stored in some internal 
representation for fd-information. The ^internal representa- 
tion of the fd-info3rmation corresponding to an fd-predicate 
looks like : 

(<no-of-args> (<list-of-i-args> 

<list-of-d-args> " 

<list-of-x-args>) ) 

where the first member of the list is n^ba^^* arguments 
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dontcare arguments. The internal representation is stored as 
a property of the atom <pred“name> under the attribute $fd. 

3.4.4 Compilation Of Fd-Infomatiom 

After the user has defined clauses for solving his 
problem and specified relevent fd-inforaation then complete 
fd- information is compiled. The compilation of fd- 
information essentially means deriving all possible func- 
tional relation among the arguments of a predicate given 
some functional relation by the user. For example user can 
specify two functional arelation for a predicate foo as shown 

(deffd (foo i d x)) 

(deffd (foo X i d)) 

then functional relation in which the first argument 
uniquely determines the third one can be derived (by transi- 
tivity) . Thus for every subset of the set of arguments of 
each fd-predicate, the set of dependent variables is com- 
puted by taking closure w.r.t. fd-information specified for 
the predicate. This information is stored in trie- 
structure. The number of arguments of an fd-predicat© along 
with the trie -structure containing fd-information is stored 
as property of the atom <pred-name> under the attribute 
$fd-trie. An outline of the algorithm for compilation of 
fd-information is given as follows 

INPUT : list of fd-predicates 

OUTPUT : Computes closure of the arguments w.r.t. func- 
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tional relations specified for an fd-predicate and stores 
it in a trie- structure. 

ALQORITHH : 

for every fd-predicate in input list do 

1. Initialisation 

arg-no <- (no of arguments of fd-predicate) 
trie-list <- nil 

arg-aet <- set of argument position of 

fd-predicate (with inceasing argument 
number) 

;* a fd-predicate with two arguments will have 
arg-set as (0 1) 

2. /“for every sub- set SS of arg-set do 
\,2.1 closure-list <- nil 

2.2 compute the closure C w.r.t. fd- information 
given fox the fd-predicate 

2.3 add list of sub-set SS and corresponding 
closure C to closure-list 

3. Construct a trie-structure T corresponding to 
closure-list. The first element of each entry 
in the closure- list acts as a key under which 

the second element is stored in the trie-structure. 

4. Add an entry ( <arg-no> T ) to tjrie-list for the 

fd-predicate. 

5. Store the trie-list as a property of sj^e 
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atom <|>ro<i-naia©> under the attribute $fd-trie. 

The compilation of fd-information and storing in the 
trie-structure makes it easy to determine the applicability 
condition for a functional relation. To determine the func- 
tional relation applicable to a chosen literal (an fd- 
predicate) in the inference, we find the set of arguments 
(with arguments positions in increasing order) which are 
ground terms in the literal and with this a key, w© traverse 
trie- structure and get set of dependent argxnnents. This 
forms the functional relation applicable to that instance of 
the literal. 

3.4.S Inferemce 
Data-Structure 

The interpreter uses an explicit stack. An iterative 
algorithm for inference is implemented, so that at any step 
complete proof-tree is accessible for the purpose of debug- 
ging etc. Each enrty in the stack corresponds to the activa- 
tion record which contains the following information for 
example qlist, all facts and rules for the chosen literal, 
association list containing variables and their bindings* 
active and passive dependency information. These informa- 
tions are represented using a list which is defined usini 
def struct as follows : 
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(def struct^ (enlixy ( i constructor make-entry (qlist 

facts 

rules 

alist 

afd 

. Pld))) 

qlist 

facts 

rules 

alist 

afd 

Pfd ) 

The advantage in defining an entry using def struct is .that 
it provides us with constructor and selector functions for 
making an entry and accessing different components of it. 


AlgoxltlsB 

;# INPUT to the interpreter is a list of literals i.e. qlist 
j!*! which is to be solved. 

qlist is renamed and the literal (next) is added at the en 

this marks the end of the proof. 

INITIALISATION OP THE STACK 

in the begining alist a-fd-list p-fd-list are nil. 

(let ((ini-stack (make-entry qlist 

(all-facts (first-of query)) 
(all-rules (first-of query)) 
nil 
nil 

nil))) 

TOP-LEVEL ITERATION 
; * initialisation of loop variables 

(do* ((stack ini-stack) 

(top-stack (first-of stack) (first-of stack)) 

(qlist-lcl (entry-qlist top-stack) 

(entry-qlist top-stack)) 

(alist-lcl (entry-alist top-stack) 

(entry-alist top-stack)) 

(a-fd-list (entry-afd top- stack) 

(entry-afd top-stack)) 

(p-fd-list (entry-pfd top-stack) 

(entry-pfd top- stack)) 

(query (subst-variables (first-of qliet)) . 

( subat-variables (first-of qlist))) 

(over-flag nil)) 

((or (null stack) over-flag) 

;* TERMINATION condition 



56 


(cond (over-flag 

qllst is auooeasfol 
t) 

(t 

qllst is anauocessful 
'$f ail-inf er))) 

;* body of top-level loop 

(oond ((null qlist-lcl) 

Sub-problem is solved. This arises when the argument 
;* of negation is successful. 

(setq over-flag t)) 

(t 

Inference cycle with the top-stack begins here. 
Search for a solution is made in depth-first 
;* manner. First literal in the qlist is selected 
;* as query to be solved. 

(oond ((its a non-database query) 

query is a non-database query. 
i* it could be any of the following : 

iK>tf oooputepred, procpred 
;* cmtt next etc. 

(let ((res (solve query))) 

(cond ((not (fail-p res)) 

query succeeds then 

(modif y-top-stack) ) 

(t 

query fails so backtrack 

(pop-out-top-stack) ) ) ) ) 

(t 

;* Its a database query. 

;* A clause needs to be chosen for solving 
the query. 

;* ITERATION FOR CHOOSING A CLAUSE 

(do* ( (clauses-to-try (get-clauses top-stack) 

(get-clauses top-stack)) 

(clause (rename-variables (first-of claui^es)) 
(rename-variables (first-of clauses))) 

(Icl-res (unify query (asrt-conseq clause) alist-lcl) 
(unify query (asrt-conseq clause) alist-lcl)) 
($contra-f lag nil) 

($bt-pred nil) 

($bt-flag nil) ) 

((or (null clauses-to-try) $contra-flag) 

;* TERMINATION condition for iteration. 

Either query has failed (i.e. no clauses found 
;* for the query) or contradictory information 
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is found w.r.t. some fd~infonaation. 

I * BACKTRACK el'bher naively or in a res'tric'ted 
;* manner . 

(oond ($bt--flag (perform restricted backtracking)) 

(t (perform naive backtracking)))) 

(oond ((unification succeeded) 

(oond ((query is an fd-predicate with non-nil 
dependent arguments) 

(cond ((unification instantiates only 
dependent arguments ) 

restrict query against backtrackin 

(modify top-stack) 

(push new top-stack)) 

(t 

Usual backtracking 

(modify top- stack) 

(push new top-stack)))) 

(t 

query either not an fd-predicate 
or nil dependent arguments 

(modify top-stack) 

(push new top-stack) ) ) ) 


Unification has failed. 

(oond ((active-dependencies present) 

(oond ((failure violates 

active-dependencies) 

( set backtracking point) ) ) ) ) 

(cond ((query is fd-predicate with non-nil. 
dependent arguments) 

(cond ((failure due to dependent arguments 
(cond ((failure due to 

dependent arguments only) 

;* contradictory informatioi 
; * is present 

(setq $contra-f lag t) ) ) ) 

(t ’ try-rest -of-the-rules) ) ) 

( t ’ try-rest-of -the-rules ))))))))))) 
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3.5 ConoXttslon 

We have provided a facility for specifying functional 
relation information in logic programming and developed an 
interpreter which makes use of such information. We found 
that with the help of such facility user can eliminate 
unnecessary recomcutation of goal. Further the specification 
of fd~ information is not dependent on the inference strategy 
used by the interpreter but rather it is global and declara- 
tive in nature. 
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AFFEUDIX I 

E(if0rence Hanual For Yllffil 


VlWiI , a logic prograimaing shell with some facilities 
which are specially suitable for developing an expert- 
systwB* is developed at IITK. A suamtary of commands for 
defining assertions. Issuing goal etc are given here. 


Defining Assertions 

For defining assertions following commands are given 

(def assert <a8rt-name> <conseq> <- <antecl> ... <antecn>) 

If literals in the antecedent of an assertion are absent 
thMin it defines a fact otherwise it defines a rule. 

Sach literal in the antecedent or consequent of an 
assertion looks like 

( <predlQate-nBme> <argl> , , J* <arga> ) 

Posing QiunRr 

A query is asked by specifying the literals in the fol- 
lowing way 

(goal <literall> ... <literaln> ) 

Remark : For defining question rules computational 
predicates, defproo predicates one may refer to Vllffll manual 
and VIDHI tutorial. 

Functional Relations Information 

The functional relation information correspondizxg to an 
fd-predioate, in the interpreter descibed in chapter 3, is 
specified as 

(deffd (pred-name <argl> <arg2> .... <argn> ) ) 
where each <argi> c<?uld be any of the following 

i ; if <argi> is an independent argument 



^ <argi> is a dependen't argunen't 

at •• If <argl> is neither an independent nor a 
dependent argument. 

When f d^inf omation is specified then before posing a Query 
user must ocnspiie the fd~information by giving the command 

(fd~oonpile) 


tSeta-Control 

For defining meta^clauses same syntactic frameviork is 
used. In the consequent position of a meta-clause only 
meta-predicate should appear. The details (syntax and seman- 
tics) of meta-predicates is described in chpter 2. 

irj5*ftCNSif 'ityQMdi 

The user can give a command 
(debug) 

ffhich will print the stack, in each Inference cycle. For see- 
ing the contents of stack, in each inference cycle, in case 
of meta-control ( interpreter described in chapter 2 ) user 
must give the o<mmuid 
(mdebug) 

The* trace facility is iu^lemented in meta-control inter- 
preter only, the user can set Idie trace in the inference by 
giving following jsommand 

It will print QOili, CtMm and BESOLVENT in each inference 
cycle. For resetting the trace user can give the following 

OOMImllCI 


(resetmtraoe) 



APPENDIX 2 


TRACE OF THE EXAMPLE 


Sxa«pl*d 2^1 . 


object-clauses 


{ def assert 
(def assert 
( def assert 
( def assert 
(def assert 
(def assert 
(defassesrt 
(def assert 
(def assert 
(def assert 
( def assert 
( def assert 


ex2-l (nxt red blue)) 
ex2-2 (nxt red green) ) 
ex2-3 (nxt fed yellow)) 
ex2-3 (nxt blue fed)) 
ex2-4 (nxt blue green)) 
ex2-6 (nxt blue yellow)) 
ex2-6 (nxt green red)) 
ex2~7 (nxt green blue) ) 
ex2-8 (nxt green yellow) ) 
ex2~9 (nxt yellow red)) 
ex2-10 (nxt yellow green) ) 
ex2-ll (nxt yellow blue)) 


(def assert ex2-12 (colour ?xl ?x2 ?x3 ?x4 ?x5) 

<- (nxt ?xl ?x2) 

(nxt ?xl ?x4) 

(nxt ?xl ?x5) 

, (nxt ?x2 ?x3) 

(nxt ?x2 ?x4) 

; (nxt ?x3 ?x4) 

Cnxt ?x4 ?x5)) 


a»eta-control 

(def assert inex2-l (activate ?r (nxt ?x ?y)) 
<- (totalinst (nxt ?x ?y))) 


Execution Begins 


(goal (colour ?xl ?x2 ?x3 ?x4 ?x5)) 

GOAL : (colour ?xll 

?x21 

?x31 

?x41 

?x51) 

CLAUSE ((colour ?xl4 

?x24 

?x34 

?x44 

. ?x54) < — 
({nxt ?xl4 ?x24) 
(nxt ?xl4 ?x44) 
(nxt ?xl4 ?x54) 
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(nxt ?x24 ?x34) 
(nxt ?x24 ?x44) 
(nxt ?x34 ?x44) 
(nxt ?x44 ?x54))) 
RESOLVEirr : ((colour ?xn 

?x21 

?x31 

?x41 

?x51)) 

GOAL •• (nxt ?xl4 ?x24) 

CLAUSE : ((nxt red blue)) 
RESOLVENT ; ((nxt ?xl4 ?x24) 
(nxt ?xl4 ?x44) 
(nxt ?xl4 ?x54) 
(nxt ?x24 ?x34) 
(nxt ?x24 ?x44) 
(nxt ?x34 ?x44) 
(nxt ?x44 ?x54)) 

(K)AL ; (nxt red ?x44) 

CLAUSE : <(nxt red blue)) 
RESOLVENT ; ((nxt red ?x44) 
(aaxt red ?x54) 
(nxt blue ?x34) 
(nxt blue ?x44) 
(nxt ?x34 ?x44) 
(nxt ?x44 ?x54)) 

GOAL : (nxt blue blue) 

GOAL HAS FAILED i 
RESOLVENT ; ((nxt red ?x54) 
(nxt blue ?x34) 
(nxt blue blue) 
(nxt 7x34 blue) 
(nxt blue ?x54)) 

GOAL ; (nxt red ?x44) 

CLAUSE : ((nxt red green)) 
RESOLVENT : ((nxt red ?x44) 
(nxt red ?x54) 
(nxt blue ?x34) 
(nxt blue 7x44) 
(3axt ?x34 ?x44) 
(nxt 7x44 7x54)) 
(nxt green 7x54)) 

(nxt green blue)) 


GOAL : (nxt blue 7x34) 

CLAUSE : ((nxt blue red)) 

RESOLVENT : ((nxt blue 7x34) (nxt 7x34 green)) 
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GOAL •• (nxt red green) 

CLAUSE : ( ( nxt red green ) ) 
RESOLVENT : <(nxt red green)) 

?xl=red 

?x2=blue 

?x3=red 

?x4=green 

?x6=blue 

yea 

should i try for another answer ; n 
ok 


neta-oontrol 


(defassert iaex2-l (backfall ?p ?r) 

<“ 

(not (in ?pl ?r) (subsume ?p ?pl))) 

(defassert mexS-l (backfall ?p ?r) 

<- (not (in ?pl ?r) 

( subsume ?p ?pl ) ) ) 

(defassert 11 (in ?x {?x . ?y))) 

(defassert 12 (in ?x (?y . ?s)) <- (in ?x ?z)) 


Execution Begins 


(goal (colour ?xl ?x2 ?x3 ?x4 ?x5)) 

GOAL ; (colour ?xll 

?x21 

?x31 

?x4i 

?x51) 

CLAUSE : ((colour ?xl2 

?x22 

?x32 

?x42 

?x52) <— 
((nxt ?xl2 ?x22) 
(nxt?xl2 ?x42) 
(nxt ?xl2 ?x52) 
(nxt ?x22 ?x32) 
(nxt ?x22 ?x42) 
(nxt ?x32 ?x42) 
(nxt ?x42 ?x52))) 
RESOLVENT : ((colour ?xll 

?x21 

?x31 

?x4i 

?x51)) 
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^^ 32 ) 

bmH?® ' blue red)) 

RESOttVENT : ((nxt blue ?x32) 

(nxt blue blue) 

(nxt ?x32 blue) 

<nxt blue blue)) 

25^ : (nxt blue blue) 

GOAL HAS FAILED 

resolvent ; ((nxt blue blue) (nxt red blue) 

goal : (nxt red ?x42) 

C^uSE : ((nxt red green)) 

WSOLVIHT ; ((nxt red ?x42) 

(nxt red ?x52) 

(nxt blue ?x32) 

fnxt blue ?x42) 

(nxt ?x32 ?x42) 

(nxt ?x42 ?x52)) 


(nxt blue blue) 


GOAL ; (nxt red green) 

CLAUSE : ((nxt red green)) 

RESOLVENT : ((nxt red green) (nxt green blue)) 

GOAL ; (nxt green blue) 

CLAUSE : ((nxt green blue)) 

RESOLVENT : ((nxt green blue)) 

?xl=red 

?x2=blue 

?x3=red 

?x4=green 

?x5=blue 

yes 

should t try for another answer : n 


SxaiBple 2^4 

objiect clauses 

(def assert al 
(def assert a2 
(def assert a3 
(def assert a4 
(def assert a5 
( def assert a6 
(def assert a? 
(def assert a8 


(fa a b)) 
(fa a c)) 
(fa b d)) 
(fa b e)) 
(fa d h)) 
(fa d i)) 
(fa c f)) 
(fa c g)) 
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(def assert a9 
(def assert al0 

I def assert rl 


(fa f S)) 

(fa £ k)) 

(gfa ?x ?y) 

<- (fa ?x ?z) 
(fa ?z ?y)) 


SMsta-oontrol 


(defassert ml (activate ?r (fa ?x ?y)) 

<- (atom ?y)) 


Execution Begins 


(goal (gfa ?x k)} 

(JOAL : (gfa ?xl k) 

CliAOSl *. ((gfa ?x4 ?y4) < — 

((fa ?x4 ?z4) (fa ?z4 ?y4))) 
RESOLVENT ; ((gfa ?xl k)) 

GOAL : (fa ?z4 k) 

CLAUSE : ((fa f k)) 

RESOLVENT : ((fa ?x4 ?z4) (fa ?z4 k)) 

GOAL : (fa ?x4 f) 

CLAUSE : ((fa c f)) 

RESOLVENT ; ((fa ?x4 f)) 


?x=o 

yes 

should i try for another ansv?er ; n 
ok 

(goal (gfa c ?x)) 

GOAL : (gfa c ?xl) 

CLAUSE ; ((gfa ?x4 ?y4) <— 

{(fa ?x4 ?z4) (fa ?z4 ?y4))) 
RESOLVENT : {(gfa c 7x1)) 

GOAL ; (fa c ?z4) 

CLAUSE ; ((fa c f)) 

RESOLVENT : {(fa c ?z4) (fa ?z4 ?y4)) 

GOAL : (fa f ?y4) 

CLAUSE : ({fa f j)) 

RESOLVENT ; ((fa f ?y4)) 


yes 

should i try for another answer : n 
ok 



